Thanks to Bill Huber and Mark Bowersox for their replies. I've rewritten my script based on the suggestions in Bill's email and it is now much more elegant and much, much, much faster! The principle is to assign a grid cell identifier to each point and then analyse the data while it's still in vector format, converting the results to a grid in the final step. Mark highlights a couple of useful looking extensions in his reply although I'm afraid I haven't had chance to test them out yet. Original question and responses are included below.

Janet

ORIGINAL QUESTION

I'm trying to create a grid from a point theme such that the value of each grid cell represents the number of point locations that fall within the cell. I've written an Avenue script to do the job but it's very slow (relies on creating a grid for each point) so any other suggestions would be appreciated.

SOLUTION 1 ( Thanks to Bill Huber )

>One approach is to snap the points to the centers of the grid cells and
>then do the computation.  That is, perform the statistical operations
>while the points are still in vector format and reserve the conversion to
>raster format until the very end.
>
>Here's an example.  Suppose the grid's origin is at (4069, 828) and its
>cellsize is 50.  Consider a point P at an arbitrary location (x, y).  Then
>j = ((x-4069)/50).Floor is the column index of the cell containing P and,
>similarly, i = ((y-828)/50).Floor is its row index.
>
>Suppose further that this grid has 600 columns.  Then i*600 + j provides a
>unique numeric identifier for each cell (assuming all points lie within
>the grid's extent.  You can easily remove any points that do not).
>
>Therefore, combining these ideas, you can use the Field Calculator expression
>
>         (([shape].GetY-828)/50).Floor * 600 + (([shape].GetX-4069)/50).Floor
>
>in the point theme's attribute table to compute a new "cell identifier"
>field.  Perform a table summary operation on this field, requesting (a)
>the sum of the point attributes and (b) the merged shapes.  Convert the
>resulting multipoint shapefile to a grid, using the summed attribute values.
>
>A potential problem is that differences in floating point precision (grid
>coordinates are computed in double precision, but are reported in
>ArcView's interface with less than double precision) could cause
>inaccuracies where points lie very close to cell boundaries.  To avoid
>this problem, you could first move the original points (using a copy of
>the point shapefile, of course) by means of the Field Calculator expression
>
>         ((([shape].GetX-4069)/50).Floor * 50 + 25 + 4069) @
> ((([shape].GetY-828)/50).Floor * 50 + 25 + 828)
>
>For this to work, you must begin editing the theme (rather than just its
>table), open its table, activate the [shape] field, and then use the field
>calculator.
>
>This displaces every point to the center of the cell in which it should
>belong, thereby assuring that the conversion of multipoint theme to grid
>will be consistent with the summation operation.
>
>The field calculator operations are fast.
>
>This approach can be recommended for its flexibility, for with minor
>changes it can produce grids corresponding to any summary statistic
>supported by ArcView: sum, max, min, sd, variance, first, last, average, count.

SOLUTION 2 ( Thanks to Mark Bowersox )

One way would be to create a polygon grid using the Coordinate Grid
Maker Extension - 2.240 (author: Christoph Feldkotter) found at the ESRI
scripts web page.  Then use the Select by Theme automation extension
(author: Dan Patterson) to count the points in each polygon (grid
cell).  I have not tried this but I think it should work.